This article features the first version of Snap!, Build Your Own Blocks Version 1.0 or BYOB 1.0.
BYOB 1.0 was released October 21, 2008. It was based on Scratch Version 1.3 Here is a figure from its documentation showing how a block can be made recursive.
The ability to make custom blocks was the first goal of BYOB, as reflected in its name. A limited version of this capability, allowing only command blocks, later became part of Scratch in the Version 2.0. What is described here is the current form of this feature, which changed dramatically in BYOB3.
To begin making a block, use the button at the end of each palette, the semitransparent "+" sign at the top of the palette, or the "make a block" option when right-clicking on the scripting area background.
In the dialog that appears, besides giving the block a name, the user can choose its palette category (color), its shape (command, reporter, or predicate), and whether it is for all sprites or just one.
Clicking OK opens a block editor window, essentially a separate scripting area just for this block definition. In the block editor the user can add inputs to the block, and optionally set the type of an input, as well as adding the script that defines the block's actions. The use of a separate editor window is very different from the Scratch 2.0 design of custom blocks, in which all custom blocks are purple, sprite-local, and visible in the sprite's scripting area. The color isn't so important, but the idea behind it is: The Scratch design treats a custom block as something very different from a primitive block. The Snap! design tries to make custom blocks just as good as primitive blocks; ideally, once a block is written, it might as well be primitive. The fact that Scratch custom blocks are sprite-local is a result of the fact that their definitions have to appear in the scripting area of some particular sprite. Keeping the block definitions visible in the scripting area emphasizes that a custom block is essentially an abbreviation for a script, and ensures that all of the user's code is visible to the user. But keeping the definitions visible partly defeats the purpose of writing procedures, namely, to hide details and program at a higher level of abstraction.
Another difference is the treatment of inputs to a custom block. Inside the Scratch block definition, an input is represented by a purple oval containing the name of the input. These inputs are variables, but Scratch treats a procedure input as something very different from a (global) variable. In Snap!, the inputs are orange ovals, like other variables, and their values can be changed with set blocks. Also, procedures can have local variables that aren't inputs, using the script variables ((a)::grey) @delInput @addInput ::grey block to create them. Like inputs, these script variables exist only inside the script. Every invocation of the block creates a separate set of script variables; this is particularly important when using recursion, avoiding the need for the user to construct an explicit stack.